IBIS Macromodel Task Group Meeting date: 15 November 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: * Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Michael Mirmak noted that he had emailed a new draft BIRD for "Rx Deterministic Noise Support in AMI" to the list and wanted to discuss it. ------------- Review of ARs: - Walter to create draft 4 of the file name relaxation proposal and send it to the ATM list. - Done. Walter noted that he had received feedback from Curtis on two minor corrections, but was waiting for more feedback before posting a draft 5. - Mike LaBonte to post Walter's draft 4. - Done. - Bob Ross to create BIRD 147.4 to incorporate discussed changes to BCI_ID. - Done. Bob Ross noted that he had created BIRD 147.4, but that brining this BIRD into alignment with the new file name proposal was still a work in progress. - Michael Mirmak to update his Format and Usage Out Clarifications BIRD draft based on the discussions. - Done. The updated version was mailed to the list. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Radek: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Rx Deterministic Noise Support in AMI: - Michael M.: [sharing new BIRD proposal] - Proposal email sent to ATM only, though it touches on a few issues that may be editorial in nature. - Primary purpose is introducing a new parameter, but it also makes some tweaks to the language for an existing parameter. - We have a parameter called Rx_noise, which was introduced in IBIS 6.0. - The definition involves the gaussian_rand() function. - The range for gaussian_rand() is not defined for the Rx_noise. gaussian_rand() is used in several places, but it's only defined for one of the Tx jitter params (Tx_Rj). - I'd like to define gaussian_rand() and its range, etc., wherever it's used. I'd like to make similar changes for rand(). - Longer term we might add a section at the beginning of the jitter parameters defining what we mean by gaussian_rand() and rand() up front. - Walter: I agree. - I believe the convention we used was that the first time gaussian_rand() was used it was defined (same for rand()). But you want to pull them out into a separate section and define them ahead of time, and I agree. - Michael M: If you contrast noise with jitter: - We have both Gaussian random (Tx_Rj) as well as deterministic jitter (Tx_Dj) defined. - However, our only noise parameter (Rx_noise) is a random noise. - What I'm proposing here is made up of two things: - A new parameter Rx_Dn, which defines a deterministic noise. - An alternate name for Rx_noise, Rx_Rn, which would be an alias for the existing parameter but would make it more obvious that it's random noise. - Deterministic noise is defined pretty much in parallel with the way deterministic jitter is defined. - Note that the current text for Rx_noise has a couple of typos. The defining equation uses "time" when I think we mean "voltage". I've corrected that equation. - Rx_Dn follows the same conventions, but it uses the function rand(), with its bounds defined at -.5 and +.5, multiplied by 2 * Rx_Dn. This is added to the output of GetWave(). - This parameter is completely optional. - Radek: This is a worthwhile extension. - I have issues with the terminology. I dislike "deterministic" since noise is by definition statistical. What you're referring to is adding a uniform distribution in addition to a Gaussian distribution. The use of "deterministic" is well established in jitter, but it is still somewhat incorrect terminology. I don't recall seeing "deterministic noise" terminology, so perhaps we don't need to introduce that terminology. - Michael M: I'd be perfectly happy with Rx_Gn and Rx_Un (instead of Rx_Rn and Rx_Dn respectively). - I simply used this as a parallel to the existing jitter terminology. - Radek: Yes, I understand. - Walter: We often use the term "bounded" in the definition. - "Bounded random noise", for example, might be better than deterministic. - My larger question is why? I can think of several reasons, but amplitude noise in silicon is traditionally Gaussian, which is why we implemented Rx_noise as Rx_Rn. Can you give any reasons that your people decided they needed a bounded amplitude noise? - Michael M: The simple answer is that we use the uniform distribution in our internal tools and analyses. - I'd have to do more research to figure out why we use it in our internal tools. - We'd like to be able to map one-to-one to AMI parameters. - Walter: I think that's a valid answer, and justifies adding this. - Another answer is that one can consider crosstalk noise to be bounded random noise. - Radek: Independent random variables are most frequently Guassian. - When you try to model something that does not represent the original random variables then you can get into all kinds of distributions. - I'm not sure bounded is quite the right name. What is proposed is a uniform distribution. - Michael M: I'm open to modifying the naming to bounded or uniform or both as opposed to the existing Gaussian. - This does open up one question. Is it possible there are noise parallels to other existing jitter parameters? I don't know of any others, but perhaps a generation or two from now we will need some others so we should use a nomenclature we can extend later. - Walter: I had a hand in introducing some of the probability distributions into AMI parameters, particularly for jitter. - You have Gaussian and you have uniform. Uniform really falls into two categories, deterministic and random, both of which are bounded. Here you are introducing a bounded, uniform, random distribution, Rx_BUR perhaps? - We have some other distributions like sinusoidal and dual Dirac, all of which are bounded distributions. - As a practical matter of what makes sense to implement for Rx noise, no one would use dual Dirac or sinusoidal noise. So I think for starters having Gaussian and bounded uniform probably covers what people need to do. - If you go to scopes, where they extract distributions like jitter, they basically have Guassian and bounded. It can be difficult to isolate the various kinds of bounded random jitter. - Michael M: I can certainly tweak the text to make use of Rx Gaussian and Rx bounded uniform terminology. It should be an easy fix. - I'll make changes and issue a new version. - This may, as I mentioned, require some editorial changes to move some of the definitions of rand(), guassian_rand(), etc. - Arpad: What are the names you will use for the parameters? - Michael M: I was going to use Rx_BoundedUniform and Rx_Gaussian. - I would simply maintain the existing "Rx_Noise" with a new alternate name Rx_Gaussian as an option (alias). Format and Usage Out Clarifications BIRD: - Michael M: [sharing second draft of the proposed BIRD (from latest email)] - Eliminated all references to data being passed into the model. - Only talking about data being presented to the EDA tool or the user. - Per Radek's comments, I tried to add references to Usage Dep. - Discussion: Walter and Radek noted that some of the text related to Dep was incorrect. Dep is identical to usage Out except that it is pre-processed. So Out, Info, and Dep are not allowed to be passed in to the model. Michael agreed to make these changes and send out a new version. Relaxation of IBIS filename restrictions: - Walter: [sharing preliminary draft 5 (just draft 4 with Curtis' two edits)] - Discussion: Bob Ross said he was worried about the sentence added in draft 4 that stated: A “file name” may also be a directory. (section 3, item 3) Bob said that opening this language up in this section was dangerous, because so many things that referred to this section were required to be actual files. Walter felt that many items that referred to this section were indeed actual file names, and that these would be clear from context. He noted, however, that some parameters that would refer to this section for their definition were paths instead of filenames. Bob stated that we should add explanations in the places where paths were allowable. He felt that adding this sentence to the fundamental "file name" definition section would open things up too much and cause confusion regarding the many items that must be file names and cannot be paths. Radek agreed with Bob, and said that we can remove that sentence from the global section and add language whenever necessary to say that a path is allowed for a particular item. Walter agreed to remove that sentence or change it to "may not be a directory." - Bob M: I think this is touching on the root of the problem. - Overloading "file name" is getting us into trouble because there are literal files, paths to those files, directories, DLL_ID and BCI_ID define namespaces (prefixes), etc. - Shoehorning all of those into "file name" and then trying to make every application of "file name" across the spec treat them uniformly is causing this trouble. - Bob R: Well said. - Then I overreached in BIRD 147. We had said ../ was illegal in section 3, because we don't want to refer to a file in a parent directory somewhere. But that "../" was the first example given for BCI_ID. So I took it out, but then got push back for removing it from BCI_ID. - Walter: We could certainly stop calling those "path" quantities file names. - The question then becomes, what are the naming rules for paths? - We have the rules for file names, and the point was just to say that the path quantities should follow the same rules. - We could clarify that paths follow rules for file names except they can be paths instead of full file names. - Bob R: I just noticed that tilde "~" is a legal file name character. - I'm not sure if it's a legal path character. - The same holds true for "!". - So Walter's point is well taken. We might have to define path names. - Bob M: I have a bit of concern about the potential disallowing of ".." within BCI_ID. - The purpose of BCI_ID is to define some namespace where two different independent executables can meet up and exchange information. - If those two .dlls are each executing with different working directories, then it's entirely possible that those directories will be siblings of one another, in which case it's impossible for the two .dlls to meet up without one using "../" (barring symlinks or some other trick). - Bob R: Your point is well taken. - I had stricken that "../" because it was prohibited in Section 3. - We can deal with that by adding additional language in the BCI_ID section stating that ../ is allowed. - Bob M: Yes, the EDA tool can use that "../" construct in a path. - Walter: I agree. - We should not allow "../" in filenames defined within an IBIS file. - But the EDA tool is permitted to generate paths with "../" in BCI_ID, for example. - Radek: Yes, within the IBIS file it can't refer to anything outside of its subdirectories. - But the EDA tool can provide paths outside the subdirectory path. - Bob R: Okay, could Bob M. provide a new draft of BIRD 147? - Bob M: Yes, please send me the latest current version (147.4). - Bob M: Motion to adjourn. - Bob R: Second. - Arpad: Thank you all for joining. Enjoy the holiday. We will meet again in two weeks. AR: Walter to create draft 5 of the file name relaxation proposal and send it to the ATM list. AR: Bob M. to update BIRD 147.4 draft to include discussed changes to BCI_ID. AR: Michael M. to incorporate discussed changes into the Format and Usage Out Clarifications BIRD draft. AR: Michael M. to incorporate discussed changes into the Deterministic Noise support BIRD draft. ------------- Next meeting: 29 November 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives